home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000050_owner-urn-ietf _Thu Oct 17 05:21:48 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA29923 for urn-ietf-out; Thu, 17 Oct 1996 05:21:48 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA29918 for <urn-ietf@services.bunyip.com>; Thu, 17 Oct 1996 05:21:46 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA22903  (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 05:21:44 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14941(5)>; Thu, 17 Oct 1996 02:21:41 PDT
  6. Received: by golden.parc.xerox.com id <2771>; Thu, 17 Oct 1996 02:21:29 PDT
  7. To: liberte@ncsa.uiuc.edu
  8. Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  9. In-Reply-To: <199610162154.QAA08668@ncsa.uiuc.edu> (message from Daniel
  10.     LaLiberte on Wed, 16 Oct 1996 14:54:11 PDT)
  11. Subject: Re: [URN] a possible security architecture for URNs
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Oct17.022129pdt."2771"@golden.parc.xerox.com>
  14. Date: Thu, 17 Oct 1996 02:21:29 PDT
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. I want to be able to transition from
  21.  
  22. Herman Melville's Moby Dick
  23. to
  24. LOC's Herman Melville's Moby Dick
  25. or
  26. OCLC's Herman Melville's Moby Dick
  27.  
  28. The naming scheme in SDSI not only allows relative names, but some way
  29. of merging the trees (or not, as you choose).
  30.  
  31. As long as you have a completely global name space, you don't have a
  32. way to talk about migration. By adding relative paths and later
  33. identity, you can deal with migration by asserting that there are some
  34. authorities YOU are willing to trust to assert name bindings for other
  35. entities who are no longer in the name binding game.
  36.  
  37. > I don't see how they have thought it out any more than we have.
  38. > What are we missing?
  39.  
  40. I think 'thought' is the wrong term. They've 'written' it out more
  41. than you have.
  42.  
  43. The Rivest & Lampson paper at least a *sketch* of how authority and
  44. naming and delegation might work, while the best we get from NAPTR is
  45. a hand-wave and protests that security isn't important because it
  46. might be expensive to implement.
  47.  
  48. Larry
  49.  
  50.